Indonesia
B2B, B2C, Outbound, Tax Reporting
2026-08-28
Indonesia now requires enterprises to make an explicit channel decision instead of treating electronic tax invoicing as one undifferentiated interface.
How to use this guide
A useful project outcome is not a document that merely repeats the rule. It is a traceable decision model that connects the rule to legal entities, transaction scenarios, source data, system behaviour, operating ownership and evidence.
End-to-end operating flow
A platform call is one stage inside a longer business lifecycle.
- Qualify
Determine scope, channel and document path before building the payload. - Validate
Block incomplete identities, tax facts, amounts and references before transmission. - Generate
Create the platform-specific representation with a traceable mapping version. - Submit
Use idempotency and a correlation key so retries do not silently duplicate documents. - Interpret
Convert every response into a finance-readable status and responsible action. - Deliver and reconcile
Coordinate customer delivery with the validated or reported result and ledger posting. - Retain
Archive source, payload, response, representation and later events as one evidence chain.
Country-specific decisions
01
The current channel landscape
DJP identifies Coretax DJP, PJAP integrated through host-to-host, and e-Faktur Client Desktop as the three main invoice creation channels. Desktop availability from 12 February 2025 is subject to the exclusions in the DJP announcement.
02
Channel choice is a business decision
Eligibility, transaction codes, company registration timing, invoice volume and automation needs should determine the channel. A high-volume SAP environment normally needs a controlled integration path and clear responsibility for portal exceptions.
03
Keep one operating ledger
Whichever channel creates the invoice, the enterprise still needs one view of document identity, approval, replacement, customer delivery, VAT reporting and evidence.
Treat every artifact as a separate controlled object
The commercial invoice, transmitted payload, authority response and customer document may be related, but they are not interchangeable. Their distinct identities must remain visible in monitoring, reconciliation and audit retrieval.
| Decision area | What must be decided | Evidence to retain |
|---|---|---|
| Source transaction | Identify the authoritative ERP document and the event that makes it eligible for processing. | Document key, version, company, timestamps and source status. |
| Structured payload | Generate the required national or platform representation from validated facts. | Payload version, mapping version, checksum and submission correlation ID. |
| Platform response | Interpret technical and business responses without collapsing them into one success flag. | Raw response, normalized status, reason and next action. |
| Customer representation | Deliver the legally and commercially appropriate readable document through the agreed channel. | Delivered document, recipient, channel and delivery time. |
| Adjustment chain | Link replacement, cancellation, credit/debit or other follow-on documents to the original identity. | Original reference, event history and final reconciled status. |
Failure scenarios the design must handle
- Validation rejection after the ERP invoice has already been posted.
- Network timeout where the platform may have accepted the document but the sender did not receive the response.
- Duplicate submission with a different technical message ID but the same business invoice.
- Authority acceptance without successful customer delivery or finance reconciliation.
- A later correction that breaks the link to the original submitted and delivered artifacts.
Official sources
- DJP Coretax information center
- DJP announcement PENG-13/PJ.09/2025 on e-Faktur Client Desktop
- DJP FAQ for e-Faktur Client Desktop