国家/地区
印度尼西亚
文章范围
B2B, B2C, 出站, 税务申报
最后核查
2026-08-28
印度尼西亚企业需要明确选择开票渠道，而不能把电子税务发票视为一个没有差异的单一接口。
如何使用本指南
高质量项目成果不是复述法规，而是形成一个可追溯的判断模型，把法规连接到法律实体、交易场景、源数据、系统行为、运营责任和留存证据。
端到端运营流程
平台调用只是完整业务生命周期中的一个环节。
- 资格判断
生成负载之前先确定范围、渠道和单据路径。 - 前置校验
税号、身份、金额、税务事实和原票关系不完整时必须阻断。 - 生成
使用可追溯映射版本生成平台要求的结构化表示。 - 提交
使用幂等键和关联号，避免重试静默产生重复。 - 解释响应
把每个响应转换成财务可读状态和明确责任动作。 - 交付与对账
协调客户交付、平台结果和账务状态。 - 归档
把源单、负载、响应、可读文档和后续事件保存成一条证据链。
本国关键判断
01
当前渠道格局
DJP 将 Coretax DJP、通过主机到主机集成的 PJAP 和 e-Faktur Client Desktop 列为三种主要开票渠道。自 2025 年 2 月 12 日起可使用桌面客户端，但仍需遵守 DJP 公告中的例外条件。
02
渠道选择是业务决策
应根据适用资格、交易代码、企业登记时间、发票量和自动化需求确定渠道。高发票量的 SAP 环境通常需要受控集成路径，并明确门户例外处理责任。
03
保持统一运营台账
无论通过哪个渠道创建发票，企业都需要统一管理单据身份、批准、更换、客户交付、增值税申报和证据。
把每一种产物作为独立受控对象
商业发票、报送负载、平台响应和客户文档相互关联，但不能互相替代。在监控、对账和审计调阅中，必须始终能够区分这些对象及其各自状态。
| 判断领域 | 需要明确什么 | 应保留的证据 |
|---|---|---|
| 源业务单据 | 确定权威 ERP 单据以及允许其进入电子发票流程的业务事件。 | 单据键、版本、公司、时间和源状态。 |
| 结构化负载 | 从已校验事实生成国家或平台要求的结构化表示。 | 负载版本、映射版本、校验值和提交关联号。 |
| 平台响应 | 区分技术响应和业务响应，不能压缩成一个成功标记。 | 原始响应、标准状态、原因及下一动作。 |
| 客户文档 | 通过约定渠道交付符合业务和法律要求的可读文档。 | 交付文档、接收方、渠道和时间。 |
| 后续调整链 | 把更换、取消、贷借项等后续单据连接到原始身份。 | 原票关系、事件历史和最终对账状态。 |
设计必须覆盖的失败场景
- ERP 发票已经过账，但平台校验拒绝。
- 网络超时，平台可能已接收，但发送方没有收到响应。
- 技术消息号不同、业务发票相同的重复提交。
- 平台已接受，但客户交付或财务对账仍未完成。
- 后续更正破坏了与原提交和交付文档的关联。
官方来源
- DJP Coretax information center
- DJP announcement PENG-13/PJ.09/2025 on e-Faktur Client Desktop
- DJP FAQ for e-Faktur Client Desktop
信息说明: 本指南根据所列官方来源提供一般业务信息，不构成法律、税务或会计意见。实施前应结合最新规定，并由当地专业顾问确认公司与交易的具体适用情况。